Understanding Storage Group Architecture
The Exchange
Server 2003 storage architecture consists of databases (also known as
information stores) that are grouped together within a storage group.
Each database is comprised of two files: the rich text file (.edb file)
and the streaming file (.stm file). These files are managed as a single
unit by the Microsoft Exchange Information Store service. There are
additional files, as well, that are common to the entire storage group.
E00.chk
The checkpoint file, which is used to mark which transactions in the
transaction log have been committed to the database. E00 indicates the
first storage group on a server. When you create additional storage
groups, the file name that is created will be incremented to E01, E02,
and so on.
E00.log
The current transaction log. Exchange Server 2003 first writes data to a
transaction log rather than to the database itself, which allows for
better performance and scalability.
Mailbox.edb
The rich text file. While the extension will always be .edb, the name
of the file is defined at the time the storage group is created. By
default, it will be named the same as the storage group.
Mailbox.stm
The streaming file. As with the rich text file, the name of the
streaming file is defined at the time the storage group is created.
Res1.log The
first of two reserved transaction logs. The reserved logs are used to
reserve a portion of disk space for use by Exchange Server 2003 in case
the hard disk runs out of space. This allows the Exchange Server 2003
services to shut down normally rather than crashing when the disk
becomes full.
Res2.log The second reserved transaction log. Each transaction log is 5 megabytes (MB) in size.
Tmp.edb A temporary transaction log used by Exchange Server 2003.
E00tmp.log
When the E00.log file reaches 5 MB in size, it is renamed, and another
E00.log file is created. This E00tmp.log file is used to bridge the gap
by storing transactions that occur while the process of renaming E00.log
takes place.
There are .edb and .stm
files for each database in a storage group but only one set of log files
for all databases within a storage group.
Understanding the Use of Multiple Databases and Storage Groups
Multiple storage groups can
be used for a number of purposes in an Exchange Server 2003
organization. One of the most common purposes is related to backup and
restore. Even in small companies, it is not uncommon to have over 20 GB
in e-mail, particularly if storage limits are not used. In large
organizations, 100 GB or greater in e-mail is often stored on the e-mail
servers. With Exchange Server 5.5 and earlier, only a single mailbox
store (called the private information store) is possible. As a result,
all the e-mail is stored in a single database file. That poses a
significant problem when it comes to backing up and restoring data. The
problem isn’t so much with backing up the database as it is with
restoring it. A restore typically takes twice as long as a backup, so if
you have a 100-GB mailbox store that takes eight hours to back up to
tape, you can expect it to take roughly 16 hours to restore the database
in the event of a disaster. Because e-mail is such a vital corporate
application, that length of downtime is unacceptable in most cases. That
time frame doesn’t even include the time it takes to replace any faulty
hardware and reinstall or restore Windows prior to restoring Exchange.
By using multiple
databases, you can reduce the individual mailbox store size, making
backup and restore easier to manage. However, a limitation is that you
cannot schedule backups for individual databases within a storage group
if you want them to run at different times. Backup scheduling applies at
the storage group level. So, to get around that, you would instead use
multiple storage groups, which would allow you the flexibility of
different backup schedules for each storage group.
In
addition, you can restore mailbox stores individually, in the order you
choose, in case of a disaster recovery. For example, while you are
restoring Exchange Server 2003, the executive management group requests
that getting their e-mail online be the highest priority. If you had the
executives in their own mailbox store, you could restore that database
first and get the executives’ e-mail online, then work on restoring the
rest of the company’s e-mail. Using multiple database also allows the
flexibility of taking one database offline for maintenance, or restoring
an individual database, without affecting the other databases. This
results in limiting downtime to a subset of users rather than to all of
them.
Another advantage to
using multiple storage groups is that you can configure circular
logging settings independent of each other. Circular logging
is a process that saves disk space usage by reusing the same set of log
files, overwriting older transactions with newer ones. This differs
from the process described earlier where the transaction log is renamed
when it reaches 5 MB in size and a new log is created. This is the
default behavior and can result in significant disk usage if backups are
not performed regularly. Naturally, backups should always be run on a
regular basis, generally at least once a day. When a backup is run,
transactions are committed to the database and the unnecessary log files
are deleted. With circular logging, only full backups can be run.
Incremental or differential backups cannot be used because of the way
circular logging works. As a result, if you have to restore a database,
you can restore only to your last full backup.
Caution
This
characteristic of circular logging is a very important and significant
limitation. Therefore, the use of circular logging is strongly
discouraged unless you have no other choice, such as a short-term
workaround with a failed tape backup drive and insufficient disk
resources to hold the growing log files until the tape drive is
replaced. |
By default, circular
logging is not enabled. However, if you do enable it, the setting
applies to all databases in a storage group. So, if you want to have
circular logging on a particular database but you don’t want other
databases to use circular logging, you would use a separate storage
group to house the database that needs circular logging and configure it
in the properties of the storage group.
See Also
Exchange
Server 2003 also supports Recovery Storage Groups, which are a special
type of storage group used specifically for recovering databases. . |
Adding Storage Groups and Databases
Prior to adding more
storage groups and databases, you should adequately plan for them
because they increase the complexity of administering Exchange Server
2003. Planning involves determining the business needs for the storage
group infrastructure, which usually relates to backup and restore needs
and to administrative requirements.
To
add a storage group, use Exchange System Manager. Each server running
Exchange Server 2003 can host up to four storage groups. (However,
remember that if you are using Exchange Server 2003 on a Cluster Service
cluster, you need to ensure that a storage group can hold the databases
from another node in the case of a failover.) Navigate to the server on
which you want to create the new storage group. Then, right-click the
server, point to New, and then click Storage Group. This opens a
Properties page for the new storage group. The first task is to name the
storage group. As soon as you start typing a name, Exchange Server 2003
will automatically fill in the paths to its installation directory and
use the name for the location of the transaction logs and system path.
This is shown in Figure 1.
You can change the paths,
and you probably should. Exchange Server 2003, like previous versions of
Exchange Server, performs best when the transaction logs and the
databases are on separate physical drives. This approach is also highly
recommended for improved recovery since, if a hard drive fails, it will
not take out both the transaction logs and the databases.
Important
If
the partition that the transaction logs are located on completely fills
up, the Information Store service will stop in order to prevent data
corruption. You can correct the problem by freeing up disk space and
then restarting the service. |
On
the Properties page, the Transaction Log Location defines the path to
the transaction log files. The System Path Location sets the location
for the storage of temporary and recovered files. The Log File Prefix is
not user-configurable, but after you create the storage group, you will
be able to view the prefix, such as E01, E02, and so on. The Zero Out
Deleted Database Pages setting clears deleted data from the hard drive,
at the expense of system performance. The last configuration option,
Enable Circular Logging, reduces disk usage by reusing a single
transaction log rather than creating a new one each time the 5 MB size
limit is reached.
Tip
Transaction
log files are always 5 MB in size. Exchange Server 2003 creates an
empty 5 MB file and then fills it with data. When the 5 MB size limit is
reached, a new file is created. A transaction log file that is not 5 MB
in size is almost certainly corrupted. |
Once you create a storage group, you will likely want to add a database
to it. Databases can be either mailbox stores or public stores. To add a
database, right-click the storage group in Exchange System Manager and
point to New, and then click Mailbox Store. As you can see in Figure 2, Exchange Server 2003 displays a Properties dialog box.
Some
of the properties to configure for the mailbox store have already been
discussed in this article, such as Limits and Policies. Options on the
General page that you might configure are the path for the default
public store for the database, the offline address list that should be
used by users in this mailbox store, and whether to archive all messages
sent or received by mailboxes on the server. If you choose to do this,
log files will be created that record all incoming and outgoing e-mail
messages.
Once you have added a new
database to your storage group, you can manage it just like any other
database. Likewise, if you add a mailbox store, you will have the
ability to move users to the new mailbox store.
